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DESCRIPTION 



MPEG-21 Digital Content Protection System 
BACKGROUND OF THE INVENTION 



1. FIELD OF THE INVENTION TECHMC.\L FIELD 

The present invention relates to Digital Rights Management (DRM) or 
Intellectual Property Management and Protection (IPMP) for 9~-generic digital 
content, especially relates to the protection and management of a-digital content 
10 independent of any data format. 



2. BACKGROUND OF THE RELATED ART BACKGROUND ART 

As various kinds of networks are widely deployed, it wlQ be demanded 
that digital content can be deUvered and distributed to a_user^ via such 
15 networks. notworlc besides using a^CDy or DVD, The corroaponding issuo is raised 
by content owner. Miether or not is it is.secure to sell tfeei^content in this wa y is a 
point of concern of the content owner? . 

As hard disks or other storage embedded devices become more and more 
prevalent , another issue is that how the content protection technique can ensure 
20 the entitled rights to be exercised correctly. 

As many different digital formats exis t to uso for packaging content in a 
digital form for easy transmitting over various network, question arises as to how 
tbe-protection technology can be cross'uscd among the different digital formats. 

At the same time users have more demands on the for the convenience 
25 with-of low cost for enjoying contentr-evenand sharing with their fiiends if they 
purchase such rights , to have rich user oxporionco . 

Conflict is always the^e -present since a^content owner op poses cares for 



any illega lcopv go that contont provadcrQ ore trying copying, and as a result to 
protect content H ^their content using their own proprietary ways due to laclcing of 
tbe -a lack of open protection techniques available in the marke t at that time . 



This not only brings a big barrier for a^content owner to sell content, but also 
brings a heavy cost for CE (consumer electronics) manufacturers to produce 
different versions of tfee-a_product just for matching to match wit h the various 
protection techniques which contont provider uso used by the content provider . 

MPEG-21 is trjdng to define a generic firamework to enable transparent 
10 and augmented use of digital content across a wide range of networks and 
devices used by different communities. How to protect the contents when they 
are being used across network or devices, becomes a very important item in 
MPEG-21, which is the part 4 of MPEG-21, caUed MPEG-21 IPMP (Intellectual 
Property Management and Protection) 
15 In the past, people working on a MPEG-4/2 IPMP Extension were 

required to define a content protection scheme based on a_MPEG-4/2 system 
since the aim is to protect any content if thoy arc p ackaged in a_MPEG-4/2 
format. 

In MPEG-21, a Digital Item (DI) is defined as a structured digital object 
20 for any digital content with a standard representation, identification and 
description, and it will be used as the fundamental unit of interchange, 
distribution and transaction within the M PEG'21 fi-amework. 

The Digital Item is declared and expressed using XML by Digital Item 
Declaration (DID). Besides a digital content which is represented as media 
25 resources in MPEG-21, such as video, music, and image, the DID provides the 
flexible structure to include various kinds of functional metadata. Such 
metadata is supposed to describe media resource format, to specify resource 
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protection scheme, to give the resource an identification name, and to provide 
User preference, etc. 

Besides the core part of DID technology, some other key technologies 
have also been elaborately developed or are under development. Digital Item 
5 Identification (DII), Digital Item Adaptation (DIA), Intellectual Property 
Management and Protection (IPMP), REL (Rights Expression Language)/RDD 
(Rights Data Dictionary), as well as ER (Event Reporting) are aU the important 
technologies for extensively exploiting the Digital Items' usage. AU the 
fiinctional metadata defined by these technologies can be placed into a DID 
10 document to aid the actual media resource consumption. 

A content protection and management mechanism is highly requested to 
address most of the reqviirements raised by many different application domains, 
especially in the scope of MPEG-21 domain, to reflect the market needs. 

The requirements on MPEG-21 IPMP are the problems to be targeted 
15 and solved here. 

IPMP, especiaUy MPEG-21 IPMP shall: 

(i) support the management and protection of intellectual property in 

descriptors and description schemesr; 

IPMP ooncciallv MPEG-31 IPMP ohall (ii) provide for interoperabihty 
20 so that content is able to be played anywhereri 

IPMP, oopociaUy MPEG-21 IPMP ohould i iii}_enable devices to 
dynamically discover, request, and obtain upgrades for supporting new media 
formats, IPMP tools and supportri 

IPMP, oopccially MPEG-21 IPMP ohall (iv}_provide mechanisms to 
25 reference Digital Item Descriptions as part of the language, make reference to 
external content descriptionsTi 

IPMP, Gopocially MPEG-21 IPMP ohoIL i y)_provide mechanisms to 
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associate Expressions with composite Digital Itemsri 

IPMP, oopocially MPEG'21 IPMP ohall ( viLprovide mechanisms to 
reference Containers or other aggregations of Digital Itemsri 

IPMP, CGpcciaUy MPEG-21 IPMP ohould ( viiiLflag that a particular 
Expression should be subject to protectionT-Thethe protection itselfj, (if any)^, is 
provided by an IPMP system controlling the Expression as a Digital Itemri 

IPMP, oopocially MPEG-21 IPMP ohall (viiiLprovide mechanisms to 
reference authentication schemesri 

IPMP, oopocially MPEG-21 IPMP ohall ( bOLprovide mechanisms to 
10 ensure that the IPMP is independent of the format or delivery channel of 
Digital Itemsvi 

IPMP, oopociaUy MPEG-21 IPMP ohall M ^unambiguously articulate 
requirements relating to IPMP Tool and Features Ti and 

IPMP, oopocially MPEG-21 IPMP shall ( xiLneed to identify IPMP Tools 
15 and Features to build trusted IPMP implementations. 

IPMP Tools and Features are components parts to build an 
IPMP-enabled Terminal or Peer. It should also possible for a Terminal or Peer 
to disclose its IPMP capability (IPMP Tools and Features). This makes it 
possible for a communicating Terminal or Peer to examine IPMP capability of 
20 another Terminal or Peer before deciding to engage with it. 

BRIEF SUMMARY DISCLOSURE OF THE INVENTION 
Methods of Digital Content Protection with Digital Rights Expression, 
comprising the following steps of 
25 Paroing parsing a digital content description, especially parsing a DID 

(Digital Item Declaration) in MPEG-21 scope; 

Rotrio\dng retrieving a digital content identifier (content ID) which is 
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used to identify the said digital content, especially a DII in MPEG-21 scope, or 
sub content identifier; 

DctoGting detecting a rights and protection description holder which 
contains rights and protection information appUed to the-said digital content 
with the corresponding content ID, and here the holder called IPMP 
(Intellectual Property Management and Protection) Control Graph Holder or 
REL (Rights Expression Language) -IPMP Control Graph holder; 

Retrieving retrieving a flag from the said holder which indicates if the 
said content is protected or belongs to fi^ee content; 
10 Processing processing the description information carried in the-said 

IPMP Control Graph or REL-IPMP Control Graph; 

Chocldng checking if rights descriptions or other metadata description 
is digital signed by retrieving a flag which is attached to the-said rights or other 
metadata; and if it is signed, preparing the corresponding digital signing tool 
15 which is indicated by TooUD; 

Rotrioving retrieving a key license from a protected License Manager; 
Checking checking the integrity of tbe-said rights or metadata using the 
said digital signing tool; 
I Parsing parsing t he-said rights with their conditions following the rules 

20 which is pre-defined, especially following REL rules which is defined in 
I MPEG-21 scope, and storing the said entitled rights and conditions in a buffer 
for future checking; 

Checking checking if the said content is encrypted by retrieving a flag 
which is attached to the-said content; and if it is encrypted, preparing the 
25 corresponding encrs^tion tool which is indicated by TooUD; 

I Un-protocting tho un-protecting said encrypted content using the said 

encrj^tion tool with the said IbolID, and other information; 



checking if ^fee-said content is watermarked by retrieving a 
flag which is attached to tfee-said content; and if it is watermarked, preparing 
the corresponding watermarking tool which is indicated by TooUD for further 
action; 

ProcoGsing processing user's request against the-said entitled rights and 
conditions stored in the buffer; 

Exorcising o xercising the rights requested by tho said user if it is 
entitled, and 

Acting acting on the-said un-protected content for playing, rendering, 
10 recording, modifying, deleting, adapting, etc. 



BRIEF DESCRIPTION OF THE DRAWINGS 
Figure 1 shows a Prior Art^ DID Structure with Possible Protection 
Information Included. 
15 Figure 2 shows a Prior Art: MPEG-21 IPMP Architecture. 

Figure 3 shows Content Packaging Flow Chart with separate Rights & 
Protection. 

Figure 4 shows Terminal Processing Flow Chart for Protected & 
Packaged Content with IPMP Control Graph Information. 
20 Figure 5 shows Content Packaging Flow Chart with mixed Rights & 

Protection. 

Figure 6 shows Terminal Processing Flow Chart for Protected & 
Packaged Content with REL-IPMP Control Graph Information. 

Figure 7 shows IPMP Control Graph for Rights & Protection 
25 Information Carried in DID. 

Figure 8 shows IPMP Architecture with IPMP Control Graph Processed. 
Figure 9 shows IPMP Architecture with REL-IPMP Control Graph 



Processed. 

Figure 10 shows Layout of Rights and Protection in REL-IPMP Control 

Graph. 



DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS INVENTION 



(Means of Solving the Problems) 

On the content packaging side , the above-mentioned problems are solved 

10 by: 

Bv-(i) introducing the concept of IPMP Control Graph to refer to all the 
rights and protection information which is directly associated with the content; 

&^(u) defining IPMP Control Graph or REL-IPMP Control Graph as 
protection metadata holder to contain rights and protection information which is 
15 used to package and protect the content; 

By— (id) placing rights & condition in the IPMP Control Graph or 
REL-IPMP Control Graph; 

Bv -(iv) placing content encryption information in the IPMP Control Graph 
or REL-IPMP Control Graph; 
20 Bv -(v) p lacing watermarking information in the IPMP Control Graph or 

REL-IPMP Control Graph; 

By-^yi)_placing rights protection information in the IPMP Control Graph 
or REL-IPMP Control Graph; 

Bv ^Cvii) p lacing and indicating key information which is used to encrypt 
25 content in the IPMP Control Graph or REL-IPMP Control Graph; 
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Bv -(viii) placing key/license information in the EPMP Control Graph or 
REL-IPMP Control Graph, or in Rights, DID, or somewhere indicated by 
keyLocationJ 

B ^(ix) indicating which IPMP Tool is used for encr5^tion, digital signing, 
watermarking with ToolID in the IPMP Control Graph or REL-IPMP Control 
Graph; 

Bv-(x) associating rights and protection with the protected digital content 
or its sub content using content ID or DII and sub content ID; and 

By-{xi)_placing IPMP Control Graph or REL-IPMP Control Graph in DID 
container or other appropriate place in other appUcation domainsi. 

On the terminal side , the above-mentioned problems are solved bv ^ 

Bv-Ci) parsing DID to retrieve content ID or sub content ID, and IPMP 
Control Graph or REL-IPMP Control Graph; 

Bj^^iLparsing IPMP Control Graph or REL-IPMP Control Graph to 
retrieve Rights and Protection related descriptions; 

Bv -Ciii) invoking IPMP tools which are used to protect the content or 
rights, or other metadata; 

By — Gv) retrieving key information from KeyData Holder directly of 
indirectly; 

Bv^(v) retrieving a key Ucense from a protected License Manager; 
By — (vi) un-protecting the protected content using the above obtained 
information; 

B¥ -(vii) checking Rights' integrity using the tool indicated by TooHD; 
Bv -(viii) p arsing the rights and conditions which are embedded with the 

content; 



9 

Bv ~(ix) retrieving watermarking descriptions and preparing for further 

action; 

(Operation of the Invention) 

On the content production side as shown in Figure 3, IPMP Control 
5 Graph is generated as shown in Figure 7, to contain all the rights and 
protection information which is directly associated with the content identified 
by content Identifier (CID) or DII if MPEG-21 could be used. 

The content could be watermarked using ascertain watermarking tool to 
achieve certain functions, such as finger printing, persistent association, or 
10 copyright protection by embedding CID or other information. 

The content can be encrypted by an IPMP tool with TodUDXXX, where 
XXX is the number which is registered with RA (Registration Authority), to 
indicate which encryption algorithm is used. A default tool^ such as AES^, is 
defined for simple hardware to implement. The rosultod resulting Key 
15 information could be carried in IPMP Control Graph directly or by pointing to a 
location where the whole Key information data could be found. The encryption 
key can be further encrypted and finally a Hcense could be generated and 
directly carried in either IPMP Control Graph, in REL data or other Rights 
Expression Data, or in DID itself, or in somewhere which can be indicated by 
20 KeyLocation indicator to be carried in IPMP Control Graph/REL/DID; 

However the segments of key information would also possibly be 
packaged together with the associated content segments when the protected 
content is transmitted^ via a_network^ for synchronization purpose. 

Rights can be expressed by an independent and existing technology 
25 standard such as REL defined in MPEG-21 or other Rights Expression methods, 
and such rights could be protected by digital signature for its integrityj^ 

On the content consumption side as shown in Figure 4, a packaged 
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content with rights and protection information is subjected to IPMP Control 
Graph parsing, from there it can be known if the content is protected and 
furthermore to determine whether the content is encrj^ted, watermarked, or 
rights is protected as well;. 

The corresponding protection tools would be invoked and acted on the 
protected object, the tools can be those normative tools defined by MPEG:21 
standard and hence installed in the device, or the tools can be proprietary and 
identified by tool IDs which can be downloaded from a remote location;. 

Tool is identified by a registered Tool ID, which is a flag to tell terminal 
or device to prepare the corresponding tool or locate the tool beforehand;. 

The key information is retrieved from a_KeyData Holder defined and 
carried in an IPMP Control Graph directly or indirectly, and it would also 
possibly be obtained in segment with the corresponding content segment to be 
protected if the content is distributed through network. 



The license information can be obtained from a_License Manager which 
could be a tompor tamper resistant entity to prevent any disclosure of how a 
license is retrieved by a license manager. 

Rights and content is -are un-protected by using the above key, key data, 
and protection tool. Rights is -are further parsed by Rights Parser to obtain the 
20 rights and conditions in clear form, so that the rights and conditions processing 
can be conducted. 

Therefore the un-protected content can be played back, rendered, 
modified, deleted, or adapted if there is such rights entitled for the user;. 



25 (EXEMPLARY EMBODIMENT) 

As shown in Figure 1 for the prior art [see reference 1 and 2], a digital 
content is packaged by DID with possible protection associated. 
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(REFERENCE 1, 2) 

[1] "ISO/IEC 21000-2 MPEG-21 Digital Item Declaration FDIS", ISO/IEC JTCl 
SC29AVG11/N4813, May 2002 

[2] Patent on "Apparatus of a MPEG-21 System", inventors' Zhongyang Huang, 
Ming Ji, Shengmei Shen, Taka Senoh, Takuyo Kogure, Takafumi Ueno with 
internal patent number PatO 1.028, filed in Japan in Feb.2002. 

The DID has defined a usefial model (unit 1,1 in Figure 1) formed by a 
set of abstract terms and concepts such as Container, Item, Component, Anchor, 
Descriptor, Condition, Choice, Selection, Annotation, Assertion, Resource, 
Fragment, Statement, etc (e.g.^ shown in Figure 1 unit 1.6, 1.7, 1.8) for defining 
Digital Items. 

Module 1.2 shown in Figure 1 is the overall IPMP Control Information 
used for all the items to be protected inside this container. Module 1.3 and 1.4 
are the specific protection information which is associated to the protected 
content. Module 1.5 is the DII to indicate the content ID. 

Tho further improvomonts ovor tho Prior Art aro - 

Since DID is to address static relation among each elements and it can 
be treated as file format, rights and protection information^ and c an be directly 
associated to its protected content as IPMP_Control_Graph, shown in Figure 3. 

On the other hand, key information can be carried from KeyData 
Holder in IPMP_Control_Graph directly or indirectly. It could also be 
segmented when the content is dehvered via a^network. 

Rights which might be encrj^ted is -are carried separately or together 
with protection information. 

Another Prior Art is shown in Figure 2 [see reference 3] for MPEG-21 
IPMP Architecture. 
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(REFERENCE 3) 

[3] "MPEG-21 Architecture, Scenarios and IPMP Requirements", ISO/IEC JTCl 
SC29/WG11/N5874, July 2003 

The Rights Expression Language (REL) Engine in module 2.1 is the 
5 component that determines REL authorizations, given an authorization request 
and a set of licenses and root grants. The REL Engine uses the License 
Manager to help resolve authorization queries. 

The Digital Item Manager in module 2.2 parses Digital Item 
Declarations within Digital Items. The Digital Item Manager also provides 
10 access to where the Digital Items are located , and creates Digital Item 
iNstances in module 2.3. The Digital Item Manager passes to the License 
Manager any Licenses that are embedded within Digital Item Declarations. 

The Digital Item iNstance in module 2.3 represents a Digital Item 
within a Trusted Domain. The Digital Item iNstance contains local metadata 
15 about the Digital Item, such as storage location and possibly information about 
content encryption keys. 

The License Manager in module 2.4 supports the REL Engine by 
managing the persistent state of Licenses and their authorization or revocation 
status. The License Manager is also responsible for verifying the integrity of 
20 Licenses. 

The Condition Processor in module 2.5 selects, evaluates and fulfills 
Conditions, and initiates the execution of authorized Operations (via the DIP 
Processor, generating a Right Exercise) once conditions are satisfied. 

The IPMP User Session Manager in module 2.6 orchestrates the 
25 invocation of Digital Item Operations (via the Condition Evaluator), first 
making sure that proper authorization is obtained (via the REL Engine) and 
that conditions are evaluated (via the Condition Evaluator). 
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A Right Exercise in module 2.7 is a record of having exercised a right, 
i.e., the invocation of a Digital Item Operation. It is maintained by the User 
Session Manager, and is used to associate the fulfillment of Conditions with the 
exercise of Rights. 

5 The Digital Item Processing Engine in module 2.8 executes Digital Item 

Operations, including Digital Item Methods (DIMs), Digital Item Basic 
Operations (DIBOs) in module 2.9, and Digital Item eXtended Operations 
(DIXOs) in module 2.10. The DIMs are executed by a DIM Engine, the DIXOs 
by a DIXO Engine, and the DIBOs by a DIBO Library The Digital Item 
10 Processing Engine updates the User Session State with process state 
information. 

The big issue with Figure 2 is that there is no protection information to 
be processed, interpreted and transferred, especially when content is protected 
by several tools and rights is also protected using different tools. There is no 
15 clear picture for people to know how the content is protected and how it should 
be processed. 

The second issue with Figure 2 is that the data flow from License 
Manager should not go to REL Engine since the existing REL engine defined in 
MPEG-21 REL only processes rights expression. The output fi-om license 
20 manager could contain the encryption key which is used to decrj^t the content 
controlled by an entity which should be IPMP Manager shown in Figure 9. The 
decryption itself can be done in IPMP Tbols, DIP Processor, DIME, or DIBO, or 
DIXO. 

The third issue with Figure 2 is that there is no data flow indication to 
25 I indicate where those the REL data comes firom, for the REL Engine to process. 
Such Rights Expression including rights conditions if they are expressed in 
MPEG-21 REL format, they could be carried as metadata together with DI in a 
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DID container, and processed by DI Manager. DI Manager should be changed 
into DID Parser which only parses information by following what DID is 
defined. 

The better rights and protection is designed based on the two cases. The 
5 first case is where the existing REL is employed for expressing the 
corresponding rights and conditions and a protection control mechanism is 
defined to take care of content protection including encryption, watermarking, 
key management. The second case is where the existing REL is extended by 
adding protection function which could include encryption, watermarking, key 
10 management, etc. 

Both cases are elaborated in the following sections. 

(Content Packaging and Consumption with Separate Rights and Protection) 

As in Figure 3, it is shown on the content packaging side with a^rights 

15 and protection scheme. REL in module 3.8 is the existing rights expression 
language to be used to package the relevant rights with their conditions. Other 
parts through 3.3, 3.4, 3.5, 3.6, 3.7, 3.9, 3.11, and 3.13 are the protection related 
functions. The most important part is in module 3.15, which is the IPMP 
Control Graph. It can be carried in DID container in MPEG-21, but it also can 

20 be carried in other places in different apphcation domains. 

When the content is needed to transmit via network, normally it will be 
segmented, encrjrpted and stored as Resource somewhere, and the 
corresponding time-variant key is stored as Key Information in KeyData Holder 
in IPMP Control Graph in module 3.9 directly or indirectly by pointing to a 

25 location. 

For example when the protected content is transmitted over RTP, the 
IPMP Control Graph can be carried in SDP (Section Description Protocol), 
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while the key information can be carried in the RTP header or as special case 
for video and audio packet as long as there is synchronization among 
time-variant keys and the protected video or audio data. 

Module 3.1 is to a a oign for assigning content ID, wherein DII in 
MPEG- 21 could be used here. If necessary sub content ID can be used and the 
protection can be associated with this sub content ID if the sub content needs to 
be protected. 

Module 3.2 is to placo for placing a flag in IPMP Control Graph to toll if 
indicate whether t he content is protected or free. Module 3.3 is to placo for 
placing a flag in IPMP Control Graph to indicate if there whether is 
watermarking is embedded. 

If there is watermarking embedded in the content, module 3.4 wiU 
assign watermarking (WM) TboHD for the WM tool used for this case, and 
TooUD is then recorded and placed in IPMP Control Graph. The module 3.5 will 
create WM Descriptions including watermarking Interface or API related 
information which is placed in IPMP Control Graph. 

Module 3.6 is to determine if for determining whether the content will 
be encrj^ted, and a flag for **Yes/No" will be placed in IPMP Control Graph in 
module 3.15. 

Module 3.9 is to QGoign for assigning encryption TooUD for the 
encrjrption tool used for this case, and TooUD is then recorded and placed in 
IPMP Control Graph. The module 3.7 is to place for placing Key information in 
KeyData Holder directly in IPMP Control Graph, or pointing by the Holder to 
other location. 

The encrjrption key can be further encrypted in module 3.11, and 3.13, 
and the key as a Ucense is eventuaUy placed in IPMP Control Graph, REL, DID, 
or somewhere indicated by KeyLocationl. 
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Module 3,8 is to crcato for creating and package packaging rights with 
the corresponding conditions which conforms to the existing REL standard, and 
this part could be modified and edited by distribution agents in the content 
distribution value chain. 

The module 3.10 is-fee -for p rotecting the rights metadata by digitally 
signing the rights. Module 3.12 is to aoGign for assigning ToolID for the 
verification of the digital signature, and module 3.14 is to place for placing the 
Entity_Key in IPMP Control Graph, or in DID, or in somewhere indicated by 
KeyLocation2. 

The detail of module 3.15 is shown in Figure 7 (a) as an example in the 
case of MPEG-21 where XML based approach is used to express IPMP Control 
Graph. A DI (7.2, declared by a DID 7.1) consists of two Items (7.2, 7.3), each of 
which has their identification scheme (7.4, 7.5) with respective attached media 
resource (7.8, 7.9). Module 7.6 shows the IPMP Control Graph mentioned above 
and Module 7.7 gives the actual rights expression (conditions and usage rules) 
linked to the resource. 

Figure 4 shows the Terminal Processing Flow Chart to process 
protection & Packaging Information carried in IPMP Control Graph before a 
protected content could be consumed in module 4.18. 

Module 4.1 is to paroo for parsing DID and IPMP Control Graph 
information where DID parser is required only for the case IPMP Control 
Graph is carried in DID in MPEG-21 case. 

In the case of content distribution over RTP network, IPMP Control 
Graph can be retrieved fi*om SDP to obtain, rights and protection description 
information except the key information if it is time-variant. 

Module 4.2 is to dotoct for detecting if- whether the content is protected 
or free. If it is free, it will be able to play back by module 4.18 for consumption. 
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Otherwise there are three branches to go and check in modules 4.3, 4.4, and 4.5, 
respectively. 

Module 4.3 is to dotoct for detecting i f -whether the Rights is-are 
encrypted, module 4.4 is to dotoct for detecting i ^- whether the content is 
encrypted, and module 4.5 is to dotoct for detecting i^whether the content is 
watermarked. 

If the rights is~ are protected, module 4.6 is to invoko for invoking the 
protection tool with ToolID and module 4.7 is to chock for checking the integrity 
of the rights using the tool. If the integrity is successfully verified in module 4.8, 
10 the rights will be sent to module 4.9 for parsing the rights by REL Engine 
which conforms to the existing REL standard. 

Module 4.11 is to procoso for processing the rights and conditions 
attached to the content and store storing the entitled rights and conditions in a 
buffer. In module 4.19 those rights requested by the users are subjected to 
15 checking against the rights and conditions stored in the buffer. 

If there is a„license carried in the Rights, module 4.10 is to rotriovc 
retrieves the hcense fi'om the License Manager which may be tompor tamper 
resistant (TR) protected. 

If the content is protected and encrypted, module 4.13 is to invoko 
20 invokes the encryption tool indicated by ToolID carried in IPMP Control Graph, 
module 4.14 is to rotriovo retrieves the Key Information, and module 4.12 is te 
obtaining obtaining the key license fi*om License Manager. 

License Manager here could be protected by a tompor tamper resistant 
technique if it is part of the terminal or somewhere in other places, since it wiQ 
25 provide the actual license which the decrj^tion engine will use to un-protect the 
content. 

The encryption tool can be defined as default for most of the terminals 
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to use in their implementation, while an IPMP ToolID is provided so that people 
can choose other than default an encryption tool in their special domain rather 
than a default decrption tooL If the platform is allowed to download and use a 
different encryption tool indicated by ToolID, it would achieve extensibility, 
flexibility and renewability at the same time wo will achiovo interoperability 
will be achieved across different domains. 

Key Information could be retrieved from different places^ in the case of 
content dohvorv being delivered v ia various networks. This will depend on 
where vou place the key information is placed . If you place thorn the key 
information is placed in RTF header, you can get them there, while if you place 
them as other packets like video and audio data, you can get them by following 
the same rules applied to video and audio. The time-variant key information is 
required to obtain in the same time when you need to decrypt the video and 
audio content. 

Module 4.15 is to docrvpt for decrvpting the content with the invoked 
tool, KeyData, and License, and then passed to module 4.17 for further 
processing. 

If the content is detected as watermarked in module 4.5, the 
watermarking tool with ToolID and its description data including interface wiU 
be invoked and prepared in module 4.16 for executing an action which io up to 
based upon a user's request. 

Finally module 4.17 is to oxorciGO for exercising the rights which user is 
requested based on the entitled rights & conditions, and aet -acting on the 
un-protected content which is the output of module 4.15. 

In Figure 4 Tompc r Tamper Resistant is used to protect the function of 
the License Manager to provide for providing a license, and the Rights & 
Condition Processing to prepare for preparing the rights, even content 
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decryption for obtaining un-protected content. 

Figure 8 shows a modified IPMP Architecture with REL and a_IPMP 
Control Graph separately processed. Compared to the Rights and Protection 
(IPMP Related) functions in Figure 4 and Figure 8, it is clear that there are 
5 many IPMP related functions missing in the prior art of Figure 2. Only the 
blocks in bluo color in Figure 4 which oro the including module 4.9 for the REL 
Engine, modules 4.10 and 4.12 for the License Manager, and module 4.11 for 
Conditions Processing, are introduced in the prior art as shown in Figure 2. 
Such function blocks are module 2.1, module 2.4, and module 2.5 in Figure 2. 
10 As shown in Figure 8, Module 8.11 is added for parsing and processing 

IPMP Control Graph information, and the corresponding results are passed to 
the License Manager in module 8.4r-j_REL related data is p assed to the REL 
Engine in module 8.1 after its integrity is checked, and content protection and 
watermarking information is_passed to the DI iNstanace in module 8.3 for 
15 further processing. 

Decrypting, watermarking, etc. in module 8,12, could be conducted in 
module 8.8 if such method is defined in DIME, or in module 8.9 if it is defined 
as one function of DIBO, or in module 8.10 if it is an external fimction. 

The Une 8.14 is shown for the data flow fi^om IPMP Control Graph 
20 processing module to REL Engine, and the fine 8.15 is shown for the data flow 
fi*om IPMP Control Graph processing module to NI iNstance. 

The line 8.16 is shown for shows the data flow from the License 
Manager to the un-protecting block in the module 8.12 for issuing a Hcense. 

Module 8.13 is for Event Reporting Engine which is placed in the same 
25 trusted domain compared to that in Figure 2. 

TR means Tompo r Tamper Resistance module to be used to protect 
License Manager operation and Condition Processing Operation. 
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Other modules have the similar meaning as explained in Figure 2. 



(Content Packaging and Consumption with Mixed Rights and Protection) 

In this case, there is no clear boundary between rights and protection, 
and they are mixed. The IPMP Control Graph can be considered as— a 
REL-IPMP Control Graph. 

Based on the current MPEG-21 REL or other rights expression 
language, protection of content as well as indicating fee-how to protect the 
content is not defined. In this case the existing REL has to be extended to 
10 support such protection signahng. 

As shown in Figure 5 which is based on Figure 3, Module 5.16 is 
considered as-aREL + Extension to support content protection signaling by 
extending the existing REL standard, and module 5.15 is changed into 
REL-IPMP Control Graph. Module 5.8 is the existing REL function. 
15 Other modules have the same functions as explained above. 

As in Figure 5, it is shown on the content packaging side with rights 
and protection scheme. REL in module 5.8 is the existing rights expression 
language to be used to package the relevant rights with their conditions. Other 
I parts through 5.3, 5.4, 5.5, 5.6, 5.7, 5.9, 5.11, and 5.13 are the protection related 
20 functions. The most important part is in module 5.15, which is the REL-IPMP 
Control Graph. It is carried in a^DID container in MPEG-21, but it also can be 
carried in other places when it is used in different application domains. 

When the content is noodod to needs to be transmited via a_network, 
normally it wiU be segmented, encrypted and stored as Resoxirce somewhere, 
25 and the corresponding time-variant key is stored as Key Information in the 
KeyData Holder in the REL-IPMP Control Graph in module 5.9 directly or 
indirectly by pointing to a location. 
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For example when the protected content is transmitted over RTP, the 
REL'IPMP Control Graph can be carried in SDP (Section Description Protocol), 
while the key information can be carried in the RTP header or as special case 
for video and audio packet as long as they are synchronized among time-variant 
keys and the protected video or audio data. 

Module 5.1 is to aoGi^n for assigning content ID, wherein DII in 
MPEG-21 could be used here. Module 5.2 is to place for placing a flag in the 
REL-IPMP Control Graph to toll if for indicating whether the content is 
protected or free. Module 5.3 is to placo for placing a flag in REL-IPMP Control 
10 Graph to indicate if there is watermarking embedded. 

If there is watermarking embedded in the content, module 5.4 wiU 
assign watermarking (WM) TboUD for the WM tool used for this case, and 
ToolID is then recorded and placed in the REL-IPMP Control Graph. The 
module 5.5 will create WM Descriptions including watermarking Interface or 
15 API related information which is placed in the REL-IPMP Control Graph. 

Module 5.6 is to dotormino for determining i f -whether the content wiU 
be encrypted, and a flag for "Yes/No" will be placed in the REL-IPMP Control 
Graph in module 5.15. 

Module 5.9 is to aooign for assigning encryption ToolID for the 
20 encryption tool used for this case, and the T boUD is then recorded and placed in 
REL-IPMP Control Graph. The module 5.7 is to placo for placing the Key 
information in the KevData Holder directly in REL-IPMP Control Graph, or 
pointing by the Holder to other location. 

The encryption key can be further encrypted in module 5.11, and 5.13, 
25 I and the key as a license is eventually placed in the REL-IPMP Control Graph, 
REL, DID, or somewhere indicated by KeyLocationl. 

Module 5.8 is to croato for creating and packa^o packing rights with the 



r 



22 



corresponding conditions which conforms to the existing REL standard, and 
this part could be modified and edited by distribution agents in the content 
distribution value chain. 

The module 5.10 is to protect for protecting the rights metadata by 
digitally signing the rights. Module 5.12 is to asoign for assigning TooUD for the 
verification of the digital signature, and module 5.14 is to place the Entity_Key 
in REL-IPMP Control Graph, or in DID, or in somewhere indicated by 
KeyLocation2. 

The detail of module 5.15 is shown in Figure 7 (b) as an example in the 
10 case of MPEG-21 where XML based approach is used to express REL-IPMP 
Control Graph. The figure is similar to Figure 7 (a). It uses REL-IPMP Control 
Graph (7.10) to replace 7.6 and 7.7 modules as shown in Figure 7 (a) but act as 
similar function to represent all rights and protection information. 

It can be seen fi-om the Figure 7 (b) that the REL IPMP extension is 
15 defined here to contain not only rights expression but also protection 
descriptions, and such an extension is done on the top of the existing MPEG-21 
REL or other Rights expression language since they are originally defined just 
to express rights, conditions, as well as principles and issuers. The ipmpx 
shown in the XML expression in Figure 7 (b) is the part of the extension of REL 
20 for protection. 

As shown in Figure 6 which , is based on Figure 4, Module 6.19 is 
considered as REL + Extension to support content protection as weU by the 
extended REL, and module 6.9 is the existing REL engine. Module 6.1 is 
changed into REL-IPMP Control Graph, and Module 6.0 is a separate DID 
25 parser in the case of MPEG-21. 

Other modules are the same functions as explained in the above. 

In Figure 6 it is shown for the Terminal Processing Flow Chart to 
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process protection & Packaging Information carried in REL-IPMP Control 
Graph before a protected content could be consumed in module 6.18. 

Module 6.1 is to paroo for parsing the DID and the REL-IPMP Control 
Graph information where the DID parser is required only for the-a case in 
which REL-IPMP Control Graph is carried in the DID in MPEG-21^ease. 

In the case of content distribution over the RTP network, the 
REL-IPMP Control Graph can be retrieved from the SDP to obtain rights and 
protection description information except the key information if it is 
time-variant. 

10 Module 6.2 is to dctoGt for detecting ij ^whether the content is protected 

or free. If it is free, it will be able to play back by module 6.18 for consumption. 
Otherwise there are three branches to go and check in modules 6.3, 6.4, and 6.5, 
respectively. 

Module 6.3 is to dotoct for detecting i f -whether the Rights is— are 
15 encrypted, module 6.4 is to dotoct for detecting i f -whether the content is 
encrjrpted, and module 6.5 is to dotoct for detecting if -whether the content is 
watermarked. 

If the rights is -are p rotected, module 6.6 is to invoko for invoking the 
protection tool with TooUD and module 6.7 is to chock for checking the integrity 
20 of the rights using the tool. If the integrity is successfully verified in module 6.8, 
the rights will be sent to module 6.9 for parsing the rights by REL Engine 
which conforms to the existing REL standard. 

Module 6.11 is to process for processing the rights and conditions 
attached to the content and ste^e- storing the entitled rights and conditions in a 
25 buffer. In module 6.19 those rights requested by the users are subjected to 
checking against the rights and conditions stored in the buffer. 

If there is license carried in the Rights, module 6.10 is to rotriovo 
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retrieves the license from the License Manager which may be tompor tamper 
resistant (TR) protected. 

If the content is protected and encrypted, module 6.13 is to invoke 
invokes the encryption tool indicated by the ToolID carried in the REL-IPMP 
Control Graph, module 6.14 is to rotriovo retrieves the Key Information, and 
module 6.12 is to obtaining obtains the key license from the License Manager. 

License Manager here could be protected by the tompor tamper resistant 
technique if it is part of the terminal or somewhere in other places, since it will 
provide the actual license which the decryption engine will use to un-protect the 
10 content. 

The encryption tool can be defined as a default tool for most of the 
terminals to use in their implementation, while an IPMP ToolID is provided so 
that people can choose an enciTotion tool from a special domain or case other 
than the default encrj^tion too l in thoir special domain or caso . If the platform 
15 is allowed to download and use different encrj^tion tool indicated by ToolID, it 
would achieve extensibility, flexibiHty and renewabUity at the same time we 
will achieve interoperability across different domains. 

Key Information could be retrieved from different places in the case of 
content delivery via various networks. This will depend on where you place key 
20 information. If you place them in the RTP header, you can get them there, while 
if you place them as other packets like video and audio data, you can get them 
by following the same rules applied to video and audio. The time-variant key 
information is required to obtain in the same time when you need to decrypt the 
video and audio content. 
25 I Module 6. 15 is to dccrvTJting for decrypting the content with the invoked 

tool, KeyData, and License, then passed to module 6.17 for fiirther processing. 

If the content is detected as watermarked in module 6.5, the 
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watermarking tool with the ToolID and its description data including interface 
will be invoked and prepared in module 6.16 for action which is up to user's 
request. 

Finally module 6.17 is to oxcrcisG for exercising the rights which the 
user is-requested based on the entitled rights & conditions, and aet -acts on the 
un-protected content which is the output of module 6.15. 

In Figure 6 the Tompor Tamper Resistant is used to protect the 
functioning of License Manager to provide hcense, Rights & Condition 
Processing to prepare the rights, even content decryption for obtaining 
10 un-protected content. 

Figure 9 shows fe^^a modified IPMP Architecture with the REL'IPMP 
Control Graph processed. Compared to the Rights and Protection (IPMP 
Related) functions in Figure 6 and Figure 9, it is clear that there are many 
IPMP related functions missing in the prior art of Figure 2. Only the blocks m 
15 blue color in Figure 6 which aro including the module 6.9 for the REL Engine, 
module 6.10 and 6.12 for the License Manager, and module 6.11 for the 
Conditions Processing, are introduced in the prior art as shown in Figure 2. 
Such function blocks are module 2.1, module 2.4, and module 2.5 in Figure 2. 

As shown in Figure 9, Module 9.11 is added for parsing and processing 
20 the IPMP Control Graph information, and the corresponding results are passed 
to the License Manager in module 9.4, the REL related data passed to the REL 
Engine in module 9. 1 after its integrity is checked, and content protection and 
watermarking information is passed to the DI iNstanace in module 9.3 for 
further processing. 

25 Decrjrpting, watermarking, etc. in module 9,12, could be conducted in 

module 9.8 if such method is defined in the DIME, or in module 9.9 if it is 
defined as one function of the DIBO. or in module 9.10 if it is an external 
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function. 

The line 9.14 is shown for the data flow from the REL-IPMP Control 
Graph processing module to the R EL Engine, and the line 9.15 is shown for the 
data flow from the REL-IPMP Control Graph processing module to the NX 
iNstance. 

The Hne 9.16 is shown for the data flow from the License Manager to 
the un-protecting block in the module 9.12 for issuing a license. 

Module 9.13 is for the Event Reporting Engine which is placed in the 
same trusted domain compared to that in Figure 2. 
10 TR means Tompo r Tamp er Resistance module to be used to protect 

License Manager operation and Condition Processing Operation. 

Other modules have the similar meaning as explained in Figure 2. 
In Figure 10, the Layout of the Rights and Protection in the IPMP 
Control Graph or the REL-IPMP Control Graph is shown, where the content ID, 
15 the protected object's indicator, the protection flags, and the detafl rights and 
conditions as well as the detail protection descriptions are placed and carried in 
this holder. 



(Effective of Invention) 
20 The invention is very effective when content is required to be protected 

with rights and conditions, especially such content can be in any data form and 
could be transmitted via various networks. 

The invention is effective when such protection is required to associate 
with the protected content via content ID, especially such protection 
25 information is defined as a set of descriptions attached to the protected content 
using content ID, or DII in MPEG-21; 

The invention is effective when such protection is placed in a generic 
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IPMP Control Graph holder or REL-IPMP Control Graph holder, which is clean 
and convenient for content creation, content distribution, as well as content 
consumption, and such holder could be carried in DID in MPEG-21 static file 
format or carried in SDP for RTP transmission. 

The invention is effective when each et^fee-protection is indicated by the 
ToolID so that both the defined IPMP tool and the external IPMP Tool can be 
used for flexibility, renewalbility and extensibihty. 

INDUSTRL\L APPLICABILITY! 

The present invention relates to Digital Rights Management (DRM) or 
Intellectual Property Management and Protection (IPMP) for a generic digital 
content, and especiaUv relates to the protection and management of a digital 
content independent of any data format. The invention is very effective when 
content is required to be protected with rights and conditions, especially such 
content can be in any data form and could be transmitted via various networks. 
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ABSTRACT 

Tho invention is rolatod to Digital Rights Management (DRM) or 
Intellectual Property Management and Protection (IPMP) for a-generic digital 
conten t wherein . The concQpt of a IPMP Control Graph and a.REL-IPMP Control 
Graph io introduced to carry carries p rotection signalling and rights expression 
data. Both content packaging and terminal processing relating to the above 
control graph are clearly defined and elaborated. 



